home *** CD-ROM | disk | FTP | other *** search
/ PC World Komputer 2010 April / PCWorld0410.iso / hity wydania / Ubuntu 9.10 PL / karmelkowy-koliberek-desktop-9.10-i386-PL.iso / casper / filesystem.squashfs / usr / share / doc / cron / FEATURES < prev    next >
Text File  |  1994-09-01  |  4KB  |  85 lines
  1. $Id: FEATURES,v 2.1 1993/12/28 08:34:43 vixie Exp $
  2.  
  3. Features of Vixie's cron relative to BSD 4.[23] and SysV crons:
  4.  
  5. --    Environment variables can be set in each crontab.  SHELL, USER,
  6.     LOGNAME, and HOME are set from the user's passwd entry; all except
  7.     USER can be changed in the crontab.  PATH is especially useful to
  8.     set there.  TZ can be set, but cron ignores it other than passing
  9.     it on through to the commands it runs.  Format is
  10.  
  11.         variable=value
  12.  
  13.     Blanks surrounding the '=' will be eaten; other blanks in value are
  14.     okay.  Leading or trailing blanks can be preserved by quoting, single
  15.     or double quotes are okay, just so they match.
  16.  
  17.         PATH=.:/bin:/usr/bin
  18.         SHELL=/bin/sh
  19.         FOOBAR = this is a long blanky example
  20.  
  21.     Above, FOOBAR would get "this is a long blanky example" as its value.
  22.  
  23.     SHELL and HOME will be used when it's time to run a command; if
  24.     you don't set them, HOME defaults to your /etc/passwd entry
  25.     and SHELL defaults to /bin/sh.
  26.  
  27.     MAILTO, if set to the login name of a user on your system, will be the
  28.     person that cron mails the output of commands in that crontab.  This is
  29.     useful if you decide on BINMAIL when configuring cron.h, since binmail
  30.     doesn't know anything about aliasing.
  31.  
  32. --    Weekdays can be specified by name.  Case is not significant, but only
  33.     the first three letters should be specified.
  34.  
  35. --    Months can likewise be specified by name.  Three letters only.
  36.  
  37. --    Ranges and lists can be mixed.  Standard crons won't allow '1,3-5'.
  38.  
  39. --    Ranges can specify 'step' values.  '10-16/2' is like '10,12,14,16'.
  40.  
  41. --    Sunday is both day 0 and day 7 -- apparently BSD and ATT disagree
  42.     about this.
  43.  
  44. --    Each user gets their own crontab file.  This is a win over BSD 4.2,
  45.     where only root has one, and over BSD 4.3, where they made the crontab
  46.     format incompatible and although the commands can be run by non-root
  47.     uid's, root is still the only one who can edit the crontab file.  This
  48.     feature mimics the SysV cron.
  49.  
  50. --    The 'crontab' command is loosely compatible with SysV, but has more
  51.     options which just generally make more sense.  Running crontab with
  52.     no arguments will print a cute little summary of the command syntax.
  53.  
  54. --    Comments and blank lines are allowed in the crontab file.  Comments
  55.     must be on a line by themselves; leading whitespace is ignored, and
  56.     a '#' introduces the comment.
  57.  
  58. --    (big win) If the `crontab' command changes anything in any crontab,
  59.     the 'cron' daemon will reload all the tables before running the
  60.     next iteration.  In some crons, you have to kill and restart the
  61.     daemon whenever you change a crontab.  In other crons, the crontab
  62.     file is reread and reparsed every minute even if it didn't change.
  63.  
  64. --    In order to support the automatic reload, the crontab files are not
  65.     readable or writable except by 'crontab' or 'cron'.  This is not a
  66.     problem, since 'crontab' will let you do pretty much whatever you
  67.     want to your own crontab, or if you are root, to anybody's crontab.
  68.  
  69. --    If any output is generated by a command (on stdout OR stderr), it will
  70.     be mailed to the owner of the crontab that contained the command (or
  71.     MAILTO, see discussion of environment variables, above).  The headers
  72.     of the mail message will include the command that was run, and a
  73.     complete list of the environment that was passed to it, which will
  74.     contain (at least) the USER (LOGNAME on SysV), HOME, and SHELL.
  75.  
  76. --    the dom/dow situation is odd.  '* * 1,15 * Sun' will run on the
  77.     first and fifteenth AND every Sunday;  '* * * * Sun' will run *only*
  78.     on Sundays;  '* * 1,15 * *' will run *only* the 1st and 15th.  this
  79.     is why we keep 'e->dow_star' and 'e->dom_star'.  I didn't think up
  80.     this behaviour; it's how cron has always worked but the documentation
  81.     hasn't been very clear.  I have been told that some AT&T crons do not
  82.     act this way and do the more reasonable thing, which is (IMHO) to "or"
  83.     the various field-matches together.  In that sense this cron may not
  84.     be completely similar to some AT&T crons.
  85.